Download and configuration system and method for gaming machines

ABSTRACT

The system and method allows a casino operator to re-configure one or more electronic gaming machines as part of a multicast. Where any reconfiguration requires a software package A and any dependent package B, a server is configured to combine as part of the multicast both packages A and B. The system and method also provides for scheduling reconfiguration though multi-casting. In the event any data packages are lost, corrupted or not received, those packages are repackaged and the data packets are re-sent as a multicast.

CROSS-REFERENCE TO RELATED APPLICATIONS

This patent application is a continuation application U.S. patentapplication Ser. No. 11/530,452 filed Sep. 8, 2006 and titled “DOWNLOADAND CONFIGURATION SYSTEM FOR GAMING MACHINES” which claims priority toU.S. Provisional Patent Application No. 60/716,713 filed Sep. 12, 2005and which applications are incorporated by reference herein in theirentirety. This application is related to U.S. patent application Ser.No. 11/530,450 filed Sep. 8, 2006 and titled “DOWNLOAD AND CONFIGURATIONSYSTEM FOR GAMING MACHINES”.

COPYRIGHT NOTICE

A portion of the disclosure of this patent document contains materialthat is subject to copyright protection. The copyright owner has noobjection to the facsimile reproduction by anyone of the patent documentor the patent disclosure, as it appears in the Patent and TrademarkOffice patent files or records, but otherwise reserves all copyrightrights whatsoever.

BACKGROUND

Over the years, casinos have grown in size, grandeur, and amenities inorder to attract gambling patrons. Additionally, casinos have attemptedto provide gambling patrons with a wide variety of the new and excitinggames. Given this demand, gaming machines have grown in sophisticationand features in order to captivate and maintain player interest. As aresult, casinos are able to provide a wide range and large number ofgames of chance.

For example, a casino floor may include thousands of electronic gamingmachines (EGMs) that are in communication with and monitored by thecasino's gaming network. EGMs provide an enhanced gaming experience withcomputer graphics, stereo sound, animation, and other features that havebeen developed to maintain player interest in the game. Furthermore,EGMs may include secondary networked devices such as player trackingdevices or enhanced player interfaces (e.g., Bally Gaming's iView™touch-screen display). Accordingly, there are a large number of EGMs andrelated components that need to be monitored, maintained, and serviced.

In early gaming environments, gaming machines were stand-alone devices.Security of the gaming machines was accomplished via physical locks,security protocols, security personnel, physical and video monitoring,and the need to be physically present at a machine to attempt to breachthe security of the gaming machine. By the same token, management of thegaming machines required a great deal of personal physical interactionwith each gaming machine. The ability to change parameters of the gamingmachine also required physical interaction.

In view of the increased processing power and availability of computingdevices, gaming machines have become customizable via electroniccommunications and remotely controllable. Manufacturers of gamingequipment have taken advantage of the increased functionality of gamingmachines by adding additional features to gaming machines, therebymaintaining a player's attention to the gaming machines for longerperiods of time increasing minimum bet and bet frequency and speed ofplay. This, in turn, leads to the player wagering at the gaming machinefor longer periods of time, with more money at a faster pace, therebyincreasing owner profits.

The amount of interactivity and data presentation/collection possiblewith current processor based gaming machines has led to a desire toconnect gaming machines in a gaming network. In addition to the gamingmachines themselves, a number of devices associated with a gamingmachine or with a group of gaming machines may be part of the network.It has become important for the devices within a gaming machine orcabinet to be aware of each other and to be able to communicate to acontrol server. Not only is the presence or absence of a network deviceimportant, but also the physical location of the device and the abilityto associate devices within a particular gaming machine has become anecessary component of a gaming network.

Currently, casino operators use manual methods to alter content or toreconfigure EGMs and/or other secondary networked devices. For example,a casino employee would need to physically swap out an EPROM to changegame content or the employee would need to access an attendant menu onthe EGM to alter game configurations. Given the large number of machinesand networked devices, this process is a time-consuming and costlyprocess not only in terms of operating and/or maintenance costs, butalso in terms of lost profits due to extended downtime for the EGMs.Similarly, existing approaches for software updates or downloads forEGMs are labor-intensive and costly as the EGMs. For example, atechnician typically needs to travel to the gaming machine in order toreplace existing software package media (e.g., EPROMs, CD-ROM's, CompactFlash, etc.) with new software package media. Furthermore, the softwarepackage update process may require that the EGM be disabled hours inadvance to prevent any players from using the EGM when the technician isready to perform software package changes. Alternatively, EGMs may bedisabled prior to software package updates, but the technician mustperiodically check to ensure that the EGM(s) are not being used by aplayer. Additionally, technicians may need to be supervised during theprocess of software package installation as the technician has access tocritical areas of the EGM required for configuration or of those areasof containing cash.

The process of transferring packages to an EGM over a network mayrequire a significant amount of network bandwidth during the transferperiod. Typical transfer mechanisms provide point-to-point transferwhere a Software Distribution Point (SDP) will transfer to a single EGMuntil the transfer is complete, and then the SDP may transfer to anotherEGM. When hundreds or thousands of EGM's require packages to betransferred there may be an unacceptable extended period of highbandwidth usage, since the transfers must occur sequentially.

Additionally, installing packages on an EGM can require verificationthat dependent software packages and hardware components are availablewithin the EGM. This is typically a manual process that prone to humaninterpretation and human error.

Accordingly, there remains a need to provide a system for updating andconfiguring EGMS and other networked components.

SUMMARY

Briefly, and in general terms, various embodiments are directed tomanagement of gaming devices over a network. The system allows a casinooperator to manage groups of electronic gaming machines (EGMs). Managingnew or existing collections (i.e., groups) of gaming devices reduces theeffort required to download or configure large numbers of EGMs. Forexample, new software may be downloaded to groups of EGMs from a centrallocation, and the EGMs may be configured from the central location.Accordingly, this operational efficiency reduces maintenance costs andminimizes EGM downtime due to maintenance or EGM set-up.

In one embodiment, EGMs can be updated over the network via a multicastover TCP/IP or some other suitable mechanism. A package containing gameinformation and/or configuration information is created at a server. Thepackage is delivered to an EGM over the network. The packages can bedownloaded via a background thread and may take place while the EGM isenabled or disabled or even when a player is actively playing the EGM.

The system includes a scheme for EGM's to report corrupted or missingpackets from the transfer, which the SDP will use to resend the packets.The SDP will use the multicast protocol to resend the packets,potentially reducing the network bandwidth used during error recovery.

The system includes a package validation method that uses digitalsignatures. A digital signature is provided with each package, which anEGM can use to validate the package and authenticate the origin of thepackage. The EGM will not install or use a package that does not passvalidation.

The system includes technology necessary for the System Management Point(SMP) to manage package dependencies (dependencies such as a newpackage-A which requires package-B and package-C to operate). Thistechnology can be used to confirm that new package-A dependencies areaddressed before requesting the EGM to transfer a new package.Additionally, the SMP can determine the dependencies and request thatthose packages also be transferred to the EGM.

The system includes technology necessary for the SMP to determine if apackage's dependent hardware components are available on the EGM. Theconcept is similar to the package dependencies; however the SMP cannotautomatically transfer hardware components to an EGM to satisfy packagedependencies. If a package's required hardware dependencies areavailable on the EGM, then the package transfer to the EGM will bepermitted; otherwise, the package transfer will not be permitted.

According to one method, the system may designate that a collection ofgaming machines should have a particular status at a given time. Changesor status may be applied to different collections of gaming machines.The network system allows a casino operator to define changes tosoftware inventory (i.e., via download) and to schedule configurationchanges. For example, a casino operator can define default payouts anddenominations, schedule recurring overrides for weekends, and schedule aone-time override for a holiday or casino promotion. Accordingly, thesechanges can occur without further operator interaction. As a result,casino management does not need to be in attendance every time the slotfloor assumes a new configuration.

Moreover, the configuration changes are communicated during thebackground operation of the EGM without affecting game play, and thechanges are applied at a designated convenient time (e.g., apredetermined period of time after the credit meter reaches zerocredits). Accordingly, the EGM does not need to be placed in an inactivestate prior to downloading configuration changes.

Furthermore, various methods of assignment conflict analysis andresolution are disclosed herein. Typically, conflicts will only occurfor assignments of the same type (e.g., download and configuration).Generally, download/configuration conflicts are avoided by running thedownload process before the configuration process with the exceptionthat data related to host and owner information will supersede otherassignments. Alternatively, conflicts may arise as a result of an EGMbeing a member of different collections where membership may varydepending on the moment in time. For example, switching an EGM from a 5cent denomination to a 25 cent denomination may switch the membership ofthe EGM to another collection (e.g., all 25 cent EGMs). Accordingly, thenetwork system includes various methods to resolve situations where EGMsare given improper settings (e.g., the system will filter out settingsthat the EGM does not support). As a result, these methods provideconsistent procedures as to how the network host configures EGMs whenmore than one assignment applies.

In another method, methods of pre-configuring EGMs are disclosed herein.In one method, the network system uses option templates to supportpre-configuration because a particular EGM or game theme within an EGMmay support a large number and wide variety of options. For example,option definition templates such as Combo Option templates or OptionGroup templates may be used to define the configuration of new contentbefore it is downloaded to an EGM. Additionally, a casino operator mayschedule the download of a new game theme during off-hours and have thenetwork host configure the new game theme as soon as installation iscompletes without requiring operator intervention.

Methods of automatic downloading and configuration of EGMs are alsodisclosed. In one method, the network system provides a method ofrecognizing when an EGM needs data downloads or configuration, and thenetwork coordinates these activities to avoid conflicts. For example, inone method, attempts to configure an EGM will be prevented untildownloads for the EGM are completed. In another method, the network hostautomatically restores data modules and configures an EGM if it has beenRAM-cleared or has been offline. Accordingly, an operator can monitorand manage a group of EGMs from a single terminal, thereby eliminatingthe need for slot technicians to collect configuration data and tomanually reconfigure each EGM.

In yet another method, methods of simultaneous download to multiple EGMsare disclosed herein. The network system distributes (i.e., downloads)data packages through the use multicast sessions, where the EGMs requestall or part of a data package (as directed by the download server). Thismethod may also include a lossless transport mechanism and an IPmulticast as the distribution mechanism. The multicast distributionmechanism conserves network bandwidth, can be throttled at the host, andprevents low priority activities (e.g., download) from interfering withcritical communications (e.g., vouchers or events).

Another method is directed to minimizing memory storage consumptionassociated with package downloads to EGMs. In this method, the hostdownloads a package (e.g., BLOB (Binary List of Bytes)) to the EGM. Thepackage is then authenticated and may then be installed immediately orat a later scheduled time. Once the contents of the package areinstalled on the EGM, the package may optionally be removed from theEGM. For example, portions of package may be removed by overwriting thepackage with new packages. The package's contents are tracked by theresulting versioned modules that have been installed on the EGM.

Other features and advantages will become apparent from the followingdetailed description, taken in conjunction with the accompanyingdrawings, which illustrate by way of example, the features of thevarious embodiments.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an embodiment of a gaming network that may be usedwith the system.

FIG. 2 illustrates an overview of download interaction

FIG. 3 illustrates an overview of EGM Start-up message flow.

FIG. 4 depicts the logic flow of /dev/download driver initialization.

FIG. 5 is a flow diagram illustrating a routine to validate downloadrequests and pass control to the proper handler function.

FIG. 6 is a flow diagram illustrating the add package logic of thedownload driver.

FIG. 7 is a flow diagram illustrating the download control processaddPackage logic.

FIG. 8 illustrates the message flow for the download receiver addPackageprocess.

FIG. 9 illustrates the logic flow for the DR.

FIG. 10 is a flow diagram illustrating the pre-requisite process.

FIG. 11 illustrates the logic flow for this process.

FIG. 12 is an overview of how the package is installed on the EGM.

DESCRIPTION OF EMBODIMENTS

Various network systems and methods for managing networked gamingmachines are disclosed herein. The system supports data downloads andconfiguration of gaming machines such as, but not limited to, electronicgaming machines (EGMs). With the network system, a casino operator maydefine a collection of EGMs, assign modules to one or more collectionsof EGMs, assign configuration changes to one or more collections ofEGMs, and schedule all assignments.

The system permits some or all of the software that is to be run on anEGM to be centrally stored in a software distribution library located onone or more servers. The software can be sent over a network (such as anEthernet network) as desired for initial set up of an EGM, as updatingof an EGM, game replacement, configuration, or any other desiredpurpose.

The system utilizes multicasting to download software packages to theEGMs in the background, even while full game play is ongoing. The serverdoes a single multicast transfer of one or more packages to all targetmachines. Each EGM tracks the packages and notes missing, corrupted, ordropped packets. In one embodiment, the server receives requests fromall EGMs for packets to resend and again multicasts them to all EGMs,regardless of which EGM requested which packet. The individual EGMsaccept needed missing packets and ignore other re-broadcast packets. Itshould be noted that the system is not limited to multicasttransmissions but may use HTTP, HTTPS, FTP, SFTP, and other transmissionprotocols.

It should be noted that the term EGM is intended to encompass any typeof gaming machine, including hand-held devices used as gaming machinessuch as cellular based devices (e.g. phones), PDAs, or the like. The EGMcan be represented by any network node that can implement a game and isnot limited to cabinet based machines. The system has equalapplicability to gaming machines implemented as part of video gamingconsoles or handheld or other portable devices. In one embodiment, ageo-location device in the handheld or portable gaming device may beused to locate a specific player for regulatory and other purposes.Geo-location techniques that can be used include by way of example, andnot by way of limitation, IP address lookup, GPS, cell phone towerlocation, cell ID, known Wireless Access Point location, Wi-Ficonnection used, phone number, physical wire or port on client device,or by middle tier or backend server accessed. In one embodiment, GPS andbiometric devices are built within a player's client device, which inone embodiment, comprises a player's own personal computing device, orprovided by the casino as an add-on device using USB, Bluetooth, IRDA,serial or other interface to the hardware to enable jurisdictionallycompliant gaming, ensuring the location of play and the identity of theplayer. In another embodiment, the casino provides an entire personalcomputing device with these devices built in, such as a tablet typecomputing device, PDA, cell phone or other type of computing devicecapable of playing system games.

An embodiment of a network that may be used with the system isillustrated in FIG. 1. The software distribution network consists of atop level vender distribution point 101 that contains all packages forall jurisdictions, one or more Jurisdiction distribution points 102A and102B that contain regulator approved production signed packages usedwithin that jurisdiction or sub-jurisdiction, one or more SoftwareManagement Points 103A and 103B to schedule and control the downloadingof packages to the EGM and a one or more Software Distribution Points104A and 104B that contain regulator approved production signed packagesonly used in the gaming establishment that it supports. The SoftwareDistribution Points (SDPs) 104A and 104B can communicate with SystemsManagement Points (SMPs) 105A and 105B, respectively as well as directlyto one or more EGMs 106A and 106B. (The communication between SDP andSMP is optional. A benefit is to permit the SMP and the user access tothe catalogue of software packages available on the SDP). The systemallows for rapid and secure distribution of new games and OS's from acentralized point. It makes it possible to update and modify existinggaming machines with fixes and updates to programs as well as providingmodifications to such files as screen images, video, sound, pay tablesand other EGM control and support files. It provides complete control ofgaming machines from a centralized control and distribution point andcan minimize the need and delay of human intervention at the EGM.

In one embodiment, a 1 GB compact flash card will initially be used asthe storage media in the EGMs for OS and download package storage. Asecond compact flash will be used for the storage of the production gameas it exists today. The OS compact flash will be partitioned intoproduction, backup, and download areas. The production area contains theactive OS and game management software used to allow the playing ofgames on the EGM. This part of storage will have all the file integritychecking and validation performed on it. The other areas will be used tostore backup software and data, new download packages, installation ofthe new packages and saving of NVRAM, counters, random number data andother secure information in an encrypted data format. Software downloadswill be scheduled by gaming personnel via the SMPs. The SMP notifies theindividual gaming machines they have been scheduled to receive adownload package from a specific vendor Software Distribution Point(SDP). The EGM shall then request the SDP to start sending the downloadpackage to it.

The system solves the network bandwidth usage problem by using amulticast network protocol, which the SDP uses to broadcast the transferto multiple EGM's simultaneously. The SDP will send a single transfer toa defined set of EGM's, thereby using a fraction of the networkbandwidth when compared to the point-to-point strategy. If there are Xgroups of EGM's, with each group consisting of Y EGM's, then thefollowing calculations provide a general sense of reduced networkbandwidth usage:

Multicast:  X * transferSize$\frac{{Point}\text{-}{to}\text{-}{point}\text{:}}{{Gross}\mspace{14mu} {Improvement}\text{:}}{\frac{( {X*Y} )*{transferSize}}{{1/Y}\mspace{14mu} {network}\mspace{14mu} {usage}\mspace{14mu} {with}\mspace{14mu} {multicast}}.}$

The system includes a recovery scheme to accommodate transmission erroror reception error of the package. This recovery scheme allows each EGMto report missing pieces (packets) where either not received or receivedwith errors (data corruption). The SDP logic can accumulate a list ofmissing packets and the corresponding EGM's, and use the multicastprotocol to resend the missing packets.

The specific packages that are transferred are specified by the EGM. TheEGM makes requests to the SDP using a point-to-point protocol. The SDPmay not service these requests immediately, so the EGM is permitted tooperate while waiting for the transfer and during the transfer. The EGMis responsible for logging transfers and checking the validity of thecompleted transfer. This log can be used to reconcile the packagecontent of the EGM at any given time. Additionally, the SDP will logtransfer activity and provide a means to cross check the package contentof an EGM.

An EGM validates transferred packages using a digital signature. Thisdigital signature provides authentication of the package itselfregardless of the specific SDP server that provided it, and is used todetermine if the package incurred any transmissions errors. If an EGM isunable to validate a package, then the package will not be installed orotherwise used.

The system includes technology necessary to determine if an EGM containspackages necessary to use a new package (package dependencies). If agiven package-A requires additional packages, package-B and package-C,to operate on the EGM, the dependencies can be determined from a packageheader contained within package-A. The SMP can then determine if the EGMalready contains the dependent packages, package-B and package-C, beforerequesting that package-A be transferred to the EGM. Similarly, the SMPcan automatically select the dependent packages to be transferred inaddition to the original package-A, thus fulfilling the dependencies ofpackage-A. This aspect of the system provides a level of assurance thatthe packages transferred can actually be used by the EGM.

The system includes technology necessary to determine if a package'sdependent hardware components (components) are available on the EGM. Ifpackage-X requires component-Y and component-Z, the SMP can read thecomponents of the EGM and use this information for component dependencychecking. If a package's required component dependencies are availableon the EGM, then the package transfer to the EGM will be permitted;otherwise, the package transfer will not be permitted. This aspect ofthe system provides a level of assurance that the packages transferredcan actually be used by the EGM.

The ability to transfer software directly to the EGM provides additionalalternatives when installing a new EGM on the casino floor. An EGM thatis manufactured and placed directly on the casino floor can be initiallyloaded with a boot-strap media (EPROM, CD-ROM, Compact Flash, etc.) thatcan boot the EGM and prepare communications before requesting newpackages to install. Two boot-strap methods may be used to transfersoftware to an EGM. Both methods require minimal configuration of an EGMbefore the boot-strap process can be completed. Minimal configurationconsists of the following:

1) A unique network IP Address for the EGM. This can be provided by aDHCP system, or assigned to the EGM via operator configuration.

2) A unique EGM identifier that is derived from the EGM hardware (suchas network card MAC address) or assigned to the EGM via operatorconfiguration.

3) An address of the SDP network server to make transfer requests of.This can be a hard-coded default address that may be overridden viaoperator configuration.

The simple boot-strap mode requires that EGM is also configured with thenecessary options to locate the SMP network server. This can be ahard-coded default address that may be overridden via operatorconfiguration. This address is used by the EGM to locate the SMP server,which can then assign new packages to the EGM for transfer. In oneembodiment, the EGM and its associated peripherals can be identifiedusing a scheme such as is described in U.S. patent application Ser. No.11/319,034 entitled “Device Identification” and incorporated in itsentirety herein by reference. In this embodiment, during start-up, adevice sends its MAC address out on the network. A local switch collectsMAC and IP addresses for the devices connected to it. Periodically, theswitch transmits raw Ethernet frames, USB packets, or TCP packetscontaining tables of devices and associated MAC/IP addresses. When adevice receives information about another device, the device may attemptcommunication with that device. First, a verification procedure is usedto validate the devices. Subsequently, communication is possible betweenthe devices.

The advanced boot-strap mode involves the EGM requesting a defaultboot-strap package from the SDP. The package name for this boot-strappackage is predefined and known to both the EGM and the SDP. Thisboot-strap package contains configuration files that identify thedefault software packages and configuration data. The boot-strap packagecan be customized for the specific installation (casino) and stored onthe SDP. This way all EGM's will request the predefined boot-strappackage, the SDP will transfer the boot-strap package to the EGM, andthe EGM will process the boot-strap package. When the EGM processes theboot-strap package, the EGM can read the SMP address, default EGM OSpackage, and other packages such as default peripheral firmwarepackages. At this point the EGM can request these packages from the SDP,and the SDP will begin transferring the default packages to the EGM,ultimately ending with an EGM ready for configuration.

FIG. 2 illustrates an overview of download interaction between theSystem Management Point 105, EGM 106, and Software Distribution Point104. The design consists of a download device driver which provides thecentral control logic and logic. It interfaces with the Download Class(which may be G2S or any other protocol) and a download control thread.The download control thread controls requesting and downloading packagesfrom the download distribution point server.

In operation, the System Management Point 105 sends package commands andrequests to the Download Control 206 of EGM 106 to tell it to add anddelete packages, install packages and request information about packagesand installed modules. The Download Control 206 will filter theserequests and pass then to the Download Driver 207 for processing.Requests to add packages are then given to the Download Receiver Process208 which then opens communications with the Software Distribution Point104. The Download Receiver Process 208 receives the package data fromthe Software Distribution Point 104 via a multicast (or any otherdefined transmission protocol) link 204 in multiple packets andassembles the package in compact flash. Once all packets of the packagehave been received, the package data is verified using a SHA-1verification string passed in the package header. The appropriate statusand package state information shall be passed back to the DownloadDriver 207 which passes it to the Download Control 206 for logging andpassing back to the System Management Point.

Download Driver 207

The download driver is installed when the EGM system is started. It'sprimary functions are to:

1—Initialize package and control information as stored on the compactflash.

2—Process commands to add packages and install rules from the DownloadControl 206.

3—Supply the Download Control 206 with list and status information anddownload and install events.

4—Queue add package requests for the Download Receiver process 208 andpass them to the Download Receiver 208 via a read 211 to the driver.

5—Update package the status and error conditions of packages and installrules and pass them back to the Download Control Process 206.

Download Control Thread 206

The Download Control Process 206 is either a thread running within thegame manager context or a standalone process when there is no gamemanager running on the system. It's primary tasks are:

1—Receives download commands

2—Passes the commands that it will not process on to the download driver207 for delivery to the Download Receiver process 208 and the DownloadInstaller process 209.

3—Receive download and install status from the driver and log in theappropriate log files on the EGM 106.

4—Supply the log information and package, install rule and module liststo the System Management Point 105 when requested.

Download Receiver Process 208

The Download Receiver Process 208 is responsible for communicationsbetween the EGM 106 and the Software Distribution Point 104. It'sprimary functions are:

1—Receive add package requests from the Download Driver 207.

2—Open a TCPIP link to the Software Distribution Point 104 and requestthe package defined within the add package request be sent to the EGM106.

3—Open a multicast communications port specified by the SoftwareDistribution Point 104 and receive the requested package in multiplepacket format.

4—Assemble the packets of the package into a single file.

5—Request any missed or missing packets be resent.

6—Verify the package data by calculating a SHA-1 value and matching thatagainst the SHA-1 validation string passed in the package header.

7—Send back status and error information of the package receive processto the Download Control Process 206 via the Download Driver 207.

Download Package Installer Process 209

The Download Package Installer Process 209 is responsible for installingthe packages that are downloaded from the Software Distribution Point104. It is notified of when to start installing a downloaded packagewhen a set install rule command is sent from the Systems ManagementPoint 105. It receives this command via a read to the Download Driver207. The basic functions of the Download Package Installer Process 109are:

1—Parse the set install rules to determine how to process the package.

2—Disable the EGM 106 based on the instructions in the set install rulecommand.

3—Install the package using the command file sent as part of thedownload package.

4—Clear NVRAM as instructed by the install rules.

5—Reboot the EGM 106 as instructed by the set install rules.

6—Pass back status and error information via the Download Driver 207.

EGM Initialization

FIG. 3 illustrates an overview of EGM start-up message flow. EGM 106sends a message 302 to SDP 104 requesting a package. SDP 104 replieswith a message 303 indicating package size and the multicast IP/Socketthat will be used for transmission. Message 304 from SDP 104 to EGM 106is the package data itself. If necessary, EGM 106 can request missedpackets by sending a message 305.

As noted above, the system uses multicasting to send packages tomultiple EGMs. When packets are missed and requested by an EGM, SDP 104collects a number of requests and sends out multicasts of all missedpackets to all of the EGMs. If a particular EGM does not need one ofthese re-broadcast packets, it is ignored. Otherwise, the EGM acceptsthe re-broadcast packet and uses it to complete the packagetransmission.

Download Driver

In the interface between the download driver 207 and the downloadprocesses, all set status, set error information and command informationis passed to the driver 207 via an IOCTL call. The processes use theread interface to get processing instructions from the driver 207. TheDownload Receiver 208 uses the read interface to get add packagerequests, the Download Installer Process 209 uses the read to obtain setinstall rule requests, and the Download Control Process 206 uses theread interface to receive the status and error information from theReceiver and Install processes.

/dev/download is a loadable module, “device driver” that is loaded asthe system comes up. (It is a Linux loadable module in one embodiment).DI_Init_module( ) is the first routine to gain control when the moduleis loaded. It will:

1—Allocate the download buffer used to store Download Class messages.(e.g. the G2S or other protocol)

2—Register the download support as a Linux kernel device.

3—Initialize the read queues for the processes that communicate with thedriver.

4—Initialize the storage area for package and set install rules that maybe received.

Once the driver has been installed and initialized, all further actionswill controlled by the ioctl and read function entry points into thedriver. The ioctl entry point, DL_ioctl( ), will process all the SystemManagement Point 105 requests passed through the Download ControlProcess received from the download class. The DL_read( ) entry pointservices all the read requests from:

The Download Control Process 206 for packages status and error,

-   -   The Download Receiver process 208 to pass add package requests.    -   The Download Installer 209 to receive set install rule request.

FIG. 4 depicts the logic flow of /dev/download driver initialization. Atstep 401 the Read Queue areas and semaphores are initialized. At step402 the package is initialized and the Install Rule Data Structures areset. At step 403 the driver is registered with the system and at step404 the system returns.

Once the /dev/download driver is installed and initialized, thedl_ioctl( ) driver 207 serves as the interface to the Download ControlProcess 206, and the Receiver 208 and Install 209 processes. Allrequests from System Management Point 105 are passed through DownloadControl Process 206 and either passed onto the driver 207 to beprocessed, or in the case of module and log requests, processed withinthe Download Control Process 206 itself. The dl_ioctl( ) is a command IDto determine what to do with the specific request. FIG. 5 is a flowdiagram illustrating a routine to validate download requests and passcontrol to the proper handler function.

At step 501 the particular switch that is set on the Command ID isexamined so that the request from the SMP 105 can be routed to thecorrect handler. Add and delete Package commands are provide toDL_Packages 502. Set and Delete Install rules are passed to DL_Install503. Set Status, Retrieve Status, Retrieve List commands are sent toDL_Status 504. Register processes are sent to block 505 where the Pid ofthe Process being registered is saved. Unknown commands return an errorevent at 506.

addPackage Processing Logic

The addPackage command from the Download class is processed by theDownload Control Process 206, the download driver 207 and the downloadreceiver process 208. Breaking up the processing into these three areashelps to maintain isolation between specific function for easilyadapting the code to support operation both with any protocols as wellas providing the capability to integrate different package downloadprotocols and requirements that may arise in the future. FIG. 6illustrates the download driver 207 addPackage logic. The addPackagelogic checks to see if the package already exists on the EGM and ifthere is enough room to store the package information. If so, it willsend the package information to the Download receiver's driver readqueue and the Download control driver's read queue and post the readsemaphores if a read is outstanding.

At step 601 there is an addPackage request. At step 602 it is determinedif the requested package exists. If no, the system returns a packageexists error at step 603. Otherwise the system proceeds to step 604 todetermine if the maximum number of packages is already queued. If yes, areturn queue full error is returned at step 605. Otherwise the systemproceeds to step 606 and adds addpackage information into the packagetable.

At step 607 addPackage is placed in the receiver read queue. At step 608it is determined if there is a receiver read outstanding. If not, thesystem returns normal status at step 609. Otherwise, the system posts areceiver read sleep semaphore at step 610. At step 611 the addPackagestatus is placed in the control read queue. At step 612 it is determinedif there is a control read outstanding. If no, the system returns normalstatus at steps 609. If yes, the system posts a control read sleepsemaphore at step 613 and returns normal status at step 609.

Download Control Process addPackage Logic

The download control process 206 has a thread that performs reads fromthe download driver 207. When the read is satisfied for an addPackage orpackage status, the operation of FIG. 7 is followed. The packageinformation is written to the /Packages/Packages directory using thepackage ID as the file name. A log entry is also created and written tothe package log in the /Packages/Logs directory. Finally a packagestatus message is created and sent back for delivery to the SystemManagement Point.

At step 701 the addPackage is read from the driver. At step 702 theaddPackage information is written to disk. At step 703 it is determinedif the write operation was successful. If not, an error event is createdand sent at step 704. Otherwise, a package log entry is created andwritten at step 705. At step 706 it is determined if the log write wassuccessful. If not, an error event is sent at step 707. If the log writeis successful, or after step 707, a package status message is createdand sent at step 708. At step 709 a read is issued to the downloaddriver.

Download Receiver addPackage

The Download receiver is responsible for downloading the packageidentified in the addPackage message from the Software DistributionPoint 104. FIG. 8 illustrates the message flow for accomplishing thistask. The message flow is between the SMP 105 and EGM 106, and betweenEGM 106 and SDP 104.

Within the EGM 106, the Download Receiver (DR) process 208 is the onethat communicates with the Software Distribution Server. The addPackagecommand 801 contains the IP and socket address of the DistributionServer to be contacted. The DR 208 opens the link to the SDP 104 andrequests 806 the package identified within the addPackage command besent to it. The SDP 104 responds 807 with a message containing packetsize, timeout values, the size of the package, and the multicast port toreceive the data on. The DR 208 sends download initiate status 802 anddownload progress messages 803 to SMP 105.

As data packets are downloaded 808, the DR 208 keeps track of thepackets sent and will request a resend 809 for any packets not received.Those packets are resent 810 as part of a multicast. After all packetshave been received 804, a SHA-1 value will be calculated for the dataportion of the package and compared 805 against the validation stringsent as part of the package.

FIG. 9 illustrates the logic flow for the DR 208. At step 901 the DRread is initiated. At step 902 a link is opened to the SDP 104. At step903 it is determined if a link is established. If not, a package erroris sent to the driver at step 904 and a read is issued to the driver atstep 905. Otherwise a request package is sent to the SDP at step 906.

The response from the SDP is read at step 907. At step 908 a multicastsocket is opened. Ata step 909 the status is sent to the DR via ioctl.At step 910 the DR reads from the multicast socket. At step 911 it isdetermined if there is a read timeout condition. If not, at step 912 thepacket data is saved at a specified offset and save sequence. Otherwiseit is determined at step 913 if there are any missed packets. If yes,then at step 914 a resend packet request is sent to the SDP and thesystem returns to step 909.

Otherwise at step 915 the downloaded package is validated (e.g. usingSHA-1). At step 916 it is determined if the data is validated. If not, apackage error status message is sent to the download driver at step 917.Otherwise a package validated status is sent to the download driver atstep 918 and the system returns to step 905.

deletePackage

The deletePackage command is processed by the Download Control 206 andReceiver 208 processes and by the Download Driver 207. When the downloaddriver 207 receives a deletePackage request, if the status of thepackage is not validated or there is an error, the status is reset todelete pending and the delete package command is sent to the downloadreceiver 208. The download receiver process 208 should then delete anyfiles it has created and terminate any download activity for the file.When the cleanup is complete, it will send a deleted status back to thedownload driver 207 and resume its read from the download driver 207.

When the download driver 207 receives a package deleted status, or ifthe original status of the package was validated or error, the downloaddriver 207 frees the package data save area and sends a deletePackagecomplete status to the Download controller process 206. The downloadcontroller process 206 logs the new status in the package log anddeletes the package status file from the /Packages/Packages directory.It then sends the delete complete status back to the SMP 105.

setInstallRule

The setInstallRule Download Class command is processed by the DownloadControl process 206, the Download Installer Process 209 and the DownloadDriver 207. The Download Control process 206 maintains the updatedstatus of the setInstallRule on disk and in the install rules log file,as well as sending the status back to the SMP 105 via messages. Thedownload driver 207 acts as the interface between the Download ControlProcess 206 and the Download install process 209. It will also validatethe package does not already exist and that there is enough room toprocess the install rules.

Download Installer Process—setInstallRule

Parsing of the setInstallRule command and the pre-requisite conditionscontained in the package header is the first step in installing adownload package. The package header is examined to extract theinformation as to what hardware requirements the package to be installedneeds as well as any software that needs to be on the EGM in order tosupport the package. With respect to software prerequisites, these canrefer to already installed software, or software contained in otherpackages that have been downloaded and are ready to install. FIG. 10 isa flow diagram illustrating the pre-requisite process.

At step 1001 the validation process begins. At step 1002 it isdetermined if the requisite hardware is present for the downloadpackage. If so, a table of installed hardware data is build at step1003. At step 1004 the loop of hardware prerequisites is read from thepackage header. At step 1005 it is determined if the prerequisites arein fact in installed in the hardware table. If so it is determined atstep 1006 if all the prerequisites are met. If so, return success atstep 1008. If not, return to step 1004.

If the prerequisites are not installed in the table at step 1005, aninstall error is logged at step 1009. At step 1010 the install status issent to the SMP 105 and an error is returned at step 1011.

If the hardware prerequisites are not present at step 1002, it isdetermined at step 1007 if the software prerequisites are present. If noprerequisites are specified, return success at step 1008. If yes at step1007, build a table of required software at step 1012. At step 1013build a table of available modules from the installed module inventory.At step 1014 build a table of modules from available packages. At step1015 loop through the prerequisite table.

At step 1016 determine if the prerequisites are found in the installedmodules. If the prerequisite isn't satisfied by the installed modules,step 1019 determines if the prerequisite may be satisfied by packagesthat have not yet been installed. If the prerequisite can't besatisfied, log install error at step 1009. Otherwise remove theprerequisite from the table at step 1017. At step 1018 determine if allprerequisites are satisfied. If yes return success at step 1008. If not,return to step 1014.

If 1016 is no, determine if the prerequisite is in the package table atstep 1019. If not, log install error at step 1009. If so, determine atstep 1020 if the package prerequisites are in the prerequisite table. Ifyes, return to step 1015. If not, add package modules to theprerequisite table at step 1021 and return to step 1015.

Once all the prerequisites have been met for the all the requiredpackages, the package install rules will be processed. The install rulescontain information on when to disable the machine to prevent gameplaying and if a time delay is required after disabling the game, whattrigger to use to start the installation process, and whether the hostneeds to authorize the install once all other conditions have been met.FIG. 11 illustrates the logic flow for this process.

At step 1101 the DL_Installer( ) routine is initiated. At step 1102 itis determined if the time window for the install is met. If not, thesystem waits for the install period at step 1103. Otherwise at step 1104it is determined if the disable conditions are met. If so, disable thecoin and bill collectors at step 1105. Otherwise determine if disableshould be immediate at step 1106. if not determine if there should bedisable none at step 1107. If no, determine if disable zero credit istrue at step 1108. If note return error and exit at step 1109.

If true at step 1108 determine if the disable wait time has expired atstep 1110. If not wait for the disable time at step 1111. For true at1106, 1108, 1110, or after step 1111, disable the coin and billacceptors at step 1105. After step 1105 or if true at step 1107,determine if automatic initiation is true at step 1112. If not,determine if initiate none is true at step 1113. If not determine ifinitiate operator is true at step 1114. If not, error exit at step 1116.Otherwise display waiting for initiate install at 1115.

For true at 1112 and 1113, or after 1115, determine if hostauthorization is required at step 1117. If no, start installing packageat step 1118. Otherwise determine if host authorization is received atstep 1119. If not, wait for host authorization at 1120. Otherwise startinstalling the package at step 1118.

Package Installation—Installing the package contents

Once all of the install requirements and prerequisites have beensatisfied, the package is ready to be installed. Once the installationprocess starts, it should not be cancelled or interrupted.

The package downloaded is made up of at least three distinct parts.

1—A header which contains the following information:

i. The module names, descriptions and release version number.

ii. The files and their offsets into the data package.

iii. The name of the command procedure used to install the package andits offset into the data package.

2—A SHA-1 validation string used to validate the data portion of thepackage.

3—A data portion of the package containing the installation procedurefile and all the files to be installed for this package. This datapartition may be in a compressed or uncompressed format. Currentlycompressed formats that are supported are gzip and bzip2. Othercompression techniques can be accommodated with the actual package dataitself and may be processed by the installation command file sent in thepackage data.

FIG. 12 is an overview of how the package is installed on the EGM. Atstep 1201 the package install process is initiated. At step 1202 data iscopied from the package to a file. At step 1203 it is determined if thepackage data is compressed. If yes, the system uncompresses the file atstep 1204. Otherwise at step 1205 loop through the file definition inthe package header. At step 1206 create an individual file from the fileportion of the package file. Determine if all files have been created atstep 1207. If not, return to 1205.

Otherwise execute the install file command at step 1208. At step 1209determine if a reboot is specified in InstallRule. If not, then removesetInstallRule and log and send status at step 1210 and return successat step 1211. Otherwise determine if the prerequisite packages areinstalled at step 1212. If not, log error and send status to SMP at step1213 and return error at step 1214. Otherwise set NVRAM clear conditionsand delete install rules at step 1215, and reboot the EGM at step 1216.

Alternate Package Install Handling

With the introduction of new file validation methodologies and thetransition to G2S, the system contemplates an alternate embodiment fordownload package install handling. The current Download interface can bemodified to present the Download Installer code with G2S like commands.That is, the SetInstallRule commands may be changed into setScriptcommands for processing by the Download Installed. Also, thegetScriptList and GetScriptStatus commands will map thegetInstallRuleStatus and getInstallRuleList commands.

It is assumed that all the commands dealing with download logs will behandled in the G2S support code and will not be a part of the Downloadsupport.

-   -   CURL will be used to provide the support for downloading        packages via HTTPS, SFTP, FTP, HTTP, etc. For any multicast        protocol, a locally developed protocol may be used.

This alternate embodiment is based on the following commands:

1. A separate thread is used to issue reads to the download driver toreceive setScript, deleteScript, authorizeScript commands.

2. A table of scripts is maintained. Each entry in the script table willpoint to the next entry in the script table. A global pointer will beused to point to the first script in the table. The table will bearranged in a FIFO queue and the scripts are processed in the order inwhich the setScript commands install time frames are specified. If anauthorizeScript command is received before it's setScript command, it isrejected and an error event sent back to the server sending theauthorization command.

The script table may be maintained in both memory and on disk. Thestatus of the script entry will be update on disk before the in memorycopy.

3. When any of the script commands are received the following willhappen:

-   -   setScript    -   If no setScript record exists for this script, create and        initialize script record with a state of waiting to process.    -   If other script records exist, place this into the process queue        according to its installation start time frame value.    -   If no other scripts in the process queue, place it at the        beginning of the process queue.    -   If script waiting for start install time frame and has a start        install time frame that is after the script just received, place        the already active script back into the process queue and set        the new script to waiting for start time frame    -   If machine is in disable state and currently processing another        script, just place the script into the script queue on disk.    -   deleteScript    -   If no script record for the specified script, return error, no        script present    -   If script record in process queue, remove from process queue and        send script deleted event.    -   If script is processing, and process state is installing, send        event script installing, not deleted.    -   If script is processing and not in installing state, send event        script canceled, delete script record and reset states. If        script waiting in script queue, start processing next script.    -   authorizeScript

Multiple hosts may be required to authorize a script to proceed withinstallation. Must maintain a list of authorizing hosts and set theirauthorization state when received. Installation can not proceed untilall hosts authorize it.

-   -   If no script record exists for specified script, reject        authorize command and send back an error event.    -   If processing script, set script state to what is specified in        the command for the particular host specified in the authorize        command.    -   If not processing script, set authorization state to what is        specified in command for the specified host.

Processing setScript Command

When a setScript command enters the processing state, the order in whichthings occur are:

1) Check dependencies: hardware and modules. Module dependencies can besatisfied by either already installed modules or modules that existwithin the packages being installed by the setScript. Insure to takeinto consideration that another package in the setScript could beremoving a module that may be required.

2) Check storage dependencies taking into account that a package withinthe setScript command could be removing a module and therefore freeingup storage.

3) Wait for install time frame.

4) Disable EGM according to disableType attribute.

5) Initiate processing of packages according to the initiateTypecommand.

6) Process authorizations. There can be multiple authorizationsrequired. This includes a local operator authorization as well asmultiple host authorizations.

7) Scripts may or may not contain command lists. If not command listsare included, then the package is installed based on the contents of thepackage. Command lists will only exist for removing modules or executingspecific commands on the EGM that is not related to installing orremoving packages.

8) Whenever a package is removed, its related file validation manifestmust also be removed from the system

9) Whenever a module is installed or removed from the EGM that cause amanifest to be modified, deleted or added, the system must be rebootedafter the installation completes.

10) Based on jurisdiction requirements and state specified in thesetScript command, delete the downloaded package.

Installing and Updating Module Requirements

Whenever a module is installed or updated on a system that hassufficient storage to maintain a backup copy of the operatingenvironment, the following steps are performed.

1) Reset the partition access permissions to allow writing to thepartitions.

2) Copy the production environment into the backup environment. This maybe done via a background task when an environment is activated and whilethe game is running.

3) Apply the changes to the production environment.

4) Insure that the boot.id file is set to boot the productionenvironment and that a backup environment exists.

5) Reboot the system according to jurisdictional requirements.

When processing the package, the package will either contain a tar filefor updates to the system or an image of a partition or entire storagemedia. If there is an image file, a check is performed to insure thatthe image is the correct size for the media.

When installing new games, this is performed via a tar file. A check ismade to insure that there is enough space to hold the new or updatedgame's files and manifest file. No backup will be made of an existinggame on the system. If the game fails to run, we expect that it willhave to be downloaded again from the server.

Installation Dependencies

Installation dependencies and pre-requisites are used interchangeably.Each may have a set of module, hardware and storage dependencies thatmust exist before the module can be installed. The dependency checkingis performed as follows:

-   -   Module Dependency—A module dependency is defined by it Module ID        and Release Information.    -   Hardware Dependency—The module dependency is defined by the        Hardware ID and version number    -   Storage Dependency—Defined by the storage type and the amount of        free space required.

For Release Information and hardware version number, a test flag willdefine how to identify if a dependency is met. The dependency check flagwill have the following values:

-   -   0—No check is performed.    -   1—The release number or version number must be equal to the one        of the installed hardware or module.    -   2—The release number version number must be greater than the        installed one.    -   3—The release or version must be greater than or equal to the        installed one.

setScript Command Structure

This section describes the setScript command structure that will bepassed into the download install logic.

Field Entry Field Type Description setScript ID string Unique identifierfor the setScript command startTime time_t Specifies the start timeframe of when the attached command can start processing endTime time_tSpecifies the end of the time window when the attached scripts can startprocessing disableType integer Indicates the conditions under which theEGM is to be disabled to start processing the attached scriptsinitiateType integer Indicates the events that need to happen in orderto start processing the attached command list. authorizeList stringarray A list of hosts that need to authorize the installation of thepackage. packageList string array A list of package IDs to be processedby this script command.

startTime/endTime—This is a date and time stamp that defines the startof the time and end of a time window within which a setScript commandcan start processing. None of the packages within the package liststarts processing before this date and time are reached. The endTime isthe date and time stamp after which the setScript command cannot start.The start of processing depends upon the initiateType being satisfiedand all the authorizations being met. If these are not met, then theprocessing of the setScript command is suspended until the time windowis entered again. Once the first package has started processing, allother packages will be processed regardless of the time window.

disableType—This specifies how the EGM should be disabled. The EGMcannot be disabled until the time processing time window is entered. Assoon as the disable conditions are met, the EGM will be disabled andwait for the authorizations to occur. If the authorizations do not occurwithin the processing time window, the setScript command will bediscontinued and the EGM re-enabled. The setScript command is thenplaced back into the waiting to process queue.

initiateType—Specifies what actions need to take place in order to startthe installation. This includes host authorizations, local operatorauthorization, etc. These events can occur before the EGM is disabled inthe case of host authorizations. All initiation requirements must besatisfied during the process time window.

authorizeList—This is a list of host IDs who must authorize thesetScript command to start processing. If the host specifiesauthorization not granted, then the processing of the setScript commandwill be terminated.

PackageList—This is a list of packages to be processed. The packageswill be processed in the order that they are specified within thesetScript command. Module dependencies within one package may besatisfied by module in another package within the package list.

When a package specifies that a module is to be deleted, then all thefiles within the Module manifest file will be deleted from the systemalong with the manifest file itself.

Download Package Description

This document is used to specify the detail design of download packages.Each download package is made of various sections. Each section startswith a section ID, the size of the section, and the contents of thesection. The contents of the section is dependent upon the type ofpackage section defined.

The specific package sections are:

-   -   Package Header—This describes the overall package.    -   Module Entry—A package may contain one or module entries.    -   Dependency Entry—After each module. The hardware and software        dependencies are defined for the module. There may none or        multiple dependencies for each module.    -   File Entry—Various types of file entries are defined. Each type        has its own unique ID

All the sections after the package header are considered to be part ofthe package data. A SHA 1 hash value is calculated over the entirepackage data. This hash value does not include the header in itscalculation.

Each package section contains an integer header. The first integer isthe section ID, and the second is the size of the section itself. Thefollowing sections describe the information that is contained withineach package section.

The contents of the package header can be seen in the following table:

Field Description mcnt integer Number of modules contained within thepackage ccnt integer Number of command defined in the packagecompression integer Compression applied to the package data psizeinteger Size of the package Data hsize integer Size of the header datatype integer Type of Package Time_stamp Time_t Time stamp of when thepackage was built vString char Package Data Validation String (SHA1 orHMAC) pkgId char Unique identifier of the package release char Releaseinformation of package, (Version, build No, etc) description CharDescription of package contents builderID char Identity of vender thatcreated package

The package header is the first thing contained with a package and is afixed length in size.

The package data compression types are:

Compression Description 1 Uncompressed data 2 Compressed data using gzipprotocol 3 Compressed data using bzip2 protocol

The following package type are been identified:

Package Type ID Description 1 Download Package is download from apackage distribution server 2 Upload Package is created at the EGM anduploaded to a server. 3 Command Package is downloaded from a server andonly contains commands to be run at the EGM.

Module Sections

There can be multiple module sections within a package. The modulesection is identified by the package section ID number 2 and the size isthe size of the module information as described in the table below.

Field Type Description Type integer Type of Module Action Integer Actionto take on Module (Add, update, delete) Mod Depend cnt. Integer No. ofmodule dependencies for this module Hard Depend cnt. Integer No. ofhardware dependencies for this module Strg Depend cnt Integer No. ofdefined storage dependencies Time Stamp integer Time stamp associatedwith when module built. Release Number sring Specific Release Major,Minor, Build and Version Nos. Name string Null terminate stringcontaining the name of the module. Description string An optional nullterminated string used to describe the module.

Each module is assigned a unique module name. The first three charactersof the name are manufacturer unique and used to identify themanufacturer of the module. The size of the name does not exceed 32characters in length in one embodiment, but that is by way of exampleonly.

The hardware, module, and storage dependency counts specify how many ofeach type of dependency is included in the package.

The type is used to identify the type of module. The following tableidentifiers the module type that are used:

Module Type ID Description os EGM OS module. Linux and Game kernels,libraries and utilities gm EGM Game module. fw Firmware module dt Datamodule. Contains EGM unique data. jr Jurisdiction module df DefinitionModule—Used to define new modules within the EGM cf ConfigurationModule—Used to specify configur- ation information for the OS, EGM andGame.

Package File Definitions

Files entries within the package are associated with the precedingmodule identified in the package. That is, all files entries after amodule definition is encountered until the next module or commanddefinition are associated with the module they follow. In the followingexample, module 1 has file 1 and 2 associated with it and module 2 hasfiles 3 and 4 associated with it.

Package Header Module 1 File 1 File 2 Module 2 File 3 File 4

All file definitions use the same control structure.

Field Type Description Type Integer Type file that follows File sizeinteger Size of the file File name string File name including fullyqualified path. Destination string Fully qualified path where file is tobe stored. Used for image files.

The following describes the type of files that can be included:

The manifest file section data area comprises the following 3 fields:

Field type Description Type integer Type of manifest, OS (1), Game (2)Manifest Name string Manifest file name (32 Characters Max) File databinary The manifest file contents

The type field is used to determine which manifest sub-directory to copythe manifest file into. Manifests will be copied into a directory calledmanifests and either into the OS1 or games subdirectory.

Tar File—(Package ID Type: 4)

Updates to installed modules as well as game installations will be inthe form of a tar file.

Partition Image File—(Package ID Type: 5)

The partition image section contains a complete image of a particularpartition on the EGM. Following the Section header data are theidentification of the partition to be replaced by the image, followed bythe image itself. The EGM will assign a name to the image file forprocessing at the EGM. The partition identification is a null terminatedstring. The partition that contains the manifest validation files willalways be partition one on any device. This partition can not be updatedwith the use of a partition image.

Device Image File—(Package ID Type: 6)

The device image file section contains the complete image of a device onthe EGM such as an entire compact flash. When the device image isspecified, it is assumed that the manifest files are include within theimage file itself and are therefore not included in a package manifestsection. Following the section header, is a null terminated string thatcontains the device the image is meant for, such as /dev/had, followedby the image itself. The EGM will assign a name to the image filelocally.

Dependency Sections

Hardware Dependencies (Package ID Type: 7)

The hardware dependency section identifies what hardware must exist onthe system before the previously defined module can be installed. Therecan be any number of these associated with each module in the package.The hardware dependency section is comprised of the hardware ID as knownon the EGM, a version number and the comparison type to be performed(equal, greater than, or greater than or equal).

Module Dependencies (Package ID Type: 8)

The module dependency specifies which modules must exist on the EGMbefore the previously defined module can be installed. There can be anynumber of these associated with each module in the package. The moduledependency consist of the module id, the version number for the moduleand the comparison identifier that specifies the type of comparison tobe performed against the version number (equal to, greater then, orgreater than or equal to).

Storage Dependency (Package ID Type: 9)

The storage dependency defines how much storage must exist on the EGM.The fields in the storage record specify the type of storage, RAM, ROM,disk, etc and how mush must be there or how much free space must existdepending on the type of storage specified.

Package Record Identifiers

This describes the currently assigned id values for download packagesections.

Package Section Type ID Description Package Header 1 Information uniqueto the package. Module Definition 2 Defines modules included in packageManifest File 3 Manifest File Associated with previous moduledefinition. Tar File 4 Tar file associated with previous Moduledefinition Partition Image 5 Partition Image file associated withprevious Module definition. Device Image file 6 Device Image fileassociated with previous Module definition. Hardware 7 Hardwareprerequisite/dependency associated Prerequisite with previous moduledefinition. Module 8 Module Prerequisite/dependency associatedPrerequisite with previous module definition. Storage Dependency 9Storage Prerequisite dependency associated with previous moduledefinition.

1. A system for providing software data packages to one or more gamingmachines in a communication network, each gaming machine having afeature configurable by said data packages, said system comprising: adata structure configured to store one or more software data packages A,each data package A adapted to configure of a feature of one or more ofsaid gaming machines and one or more dependent software data packages B,the configuration of said gaming machine by at least one data package Adependent upon said gaming terminal also having one or more dependentdata packages B; and a server in communication with said one or moregaming machines, said server configured to (i) determine for eachpackage A the required dependant data package(s) B, (ii) determine ifsaid one or more gaming machines includes said required dependent datapackages(s) B, (iii) package the delivery of said data package A and anyrequired dependent data packages B, (iv) transfer said data packages asa plurality of packets to said one or more gaming machines as part of amulticast over said network for reconfiguration thereof, (v) receive andcompile notifications from said gaming machines of missing or defectivedata packets and (v) based upon said compilation package said missing ordefective packets and re-send them as a multicast.
 2. The system ofclaim 1 comprising said server configured to retrieve data concerningthe settings of said one or more gaming machines and, where saidsettings do not support acceptance of one or more of said packets, toexclude said gaming machine from said multicast.
 3. The system of claim1 comprising said data structure including data corresponding to one ormore dependent hardware requirements to support configuration of saidone or more gaming machines by data package A or any dependent datapackages B, one or more of said server and said gaming machinesconfigured to determine if said gaming machines include said dependenthardware and if not to disable transfer of said configuration datapackages to said gaming machine.
 4. (canceled)
 5. A method for providingsoftware data packages to one or more gaming machines in a communicationnetwork, each gaming machine having a feature configurable by said datapackages, said system comprising: providing a data structure configuredto store one or more software data packages A, each data package Aadapted to configure of a feature of one or more of said gaming machinesand one or more dependent software data packages B, the configuration ofsaid gaming machine at least one data package A dependent upon saidgaming terminal also having one or more dependent data packages B; anddetermining for each package A the required dependant data package(s) B,determining if said one or more gaming machines includes said requireddependent data packages(s) B, delivering over said network said datapackage A and any required dependent data packages B as a plurality ofpackets to said one or more gaming machines as part of a multicast oversaid network for reconfiguration thereof, receiving and compilingnotifications from said gaming machines of missing or defective datapackets and based upon said compilation packaging said missing ordefective packets and re-sending them as a multicast.
 6. The method ofclaim 5 comprising retrieving data concerning the settings of said oneor more gaming machines and, where said settings do not supportacceptance of one or more of said packets, excluding said gaming machinefrom said multicast.
 7. The method of claim 5 comprising storing at saiddata structure data corresponding to one or more dependent hardwarerequirements to support configuration of said one or more gamingmachines by data package A and any dependent data packages B,determining at one or more of said server and said gaming machines ifsaid gaming machines include said dependent hardware and if notdisabling transfer of said configuration data packages to said gamingmachine.
 8. The method of claim 1 comprising configuring a plurality ofsaid gaming machines according to a first status, scheduling a transferof said data packages at a future time and at said future timetransferring said data packages to said one or more gaming machines aspart of a said multicast over said network for reconfiguration thereof.9. A system for providing software data packages to one or more gamingmachines in a communication network, each gaming machine having afeature configurable by said data packages, said system comprising: adata structure configured to store one or more software data packageseach containing data packets, each data package adapted to configure ofa feature of a gaming machine; and one or more servers in communicationwith said one or more gaming machines over said network, said serversconfigured to (i) determine for a plurality of gaming machines packagesrequired for a preselected configuration of said gaming machines (ii)package the delivery of said data packages, (iv) transfer said packagesas a plurality of said packets to said one or more gaming machines aspart of a multicast over said network for configuration thereof, (iii)receive and compile notifications from one or more of said gamingmachines of missing or defective data packets and (iv) based upon saidcompilation package and re-send said missing or defective packets as amulticast.
 10. The system of claim 9 comprising said one or more serversconfigured to store a plurality of selectable templates each defining agroup of software data packages for delivery to a plurality of gamingmachines.
 11. The system of claim 9 comprising said one or more serversstoring a log representing a history of package transfers to gamingmachines.